Apparatus and method for fair message exchanges in distributed multi-player games

ABSTRACT

The Fair-Order Service of the present invention delivers action messages to the server as soon as it is feasible. Because action messages from different players exhibit different reaction times with respect to an update message, the Fair-Ordering Service executed at the server dynamically enforces a sufficient waiting period on each action message to guarantee the fair processing of all action messages. In reality, the waiting period at the server is bounded because of the real-time nature of interactive games. The algorithms that offer Fair Ordering Service take into consideration delayed and out-of-order action messages. When action messages corresponding to multiple update messages are interleaved, the Fair-Ordering Service matches the action message to the appropriate update message. It accomplishes this by maintaining a window of update messages and using the reaction times for an action message for each of the update messages in the window. This enables state changes at the game server to be performed with fairness to all the players. The Fair-Order Service invention is based on a framework that uses a proxy architecture making it transparent to any specific game application. The service is well suited to client-server based, online multi-player games, where a fair order of player actions is critical to the game outcome.

RELATED APPLICATIONS

The present invention is related to U.S. Ser. No. 10/135,053 filed onApr. 29, 2002 and entitled Method and Apparatus for Supporting Real-TimeMulti-User Distributed Applications and assigned to the assignee herein,the subject matter of the above application being incorporated herein byreference.

FIELD OF THE INVENTION

The present invention relates generally to communications networks, andmore particularly to the support of real-time multi-user distributedapplications on such networks.

BACKGROUND OF THE INVENTION

Real-time, multi-user distributed applications, such as onlinemulti-player games or distributed interactive simulations (DIS), arebecoming increasingly popular due to advances in game design and theavailability of broadband Internet access to the end-user. Onlinemulti-player games can be implemented either using the peer-to-peermodel or the client-server model. In the peer-to-peer model players sendtheir actions to each other and react on the received action, whereas inthe client-server model all messages from players that carry theiractions are ordered at a single server. In the peer-to-peer model, eventconsistency has been well studied using the concepts of logical clocks,causal ordering and total ordering in distributed systems. In theclient-server model, consistency is automatically guaranteed becausemessages from all the players are only delivered at the central gameserver and, therefore, all messages follow both causal and totalordering. However, fairness in neither model has been addressed. Todaymost online multi-player games are implemented based on a client servermodel. This is due to the complexity of a peer-to-peer model basedimplementation as well as security restrictions that preventpeer-to-peer communication. The present invention focuses on games basedon the client-server model. The design and implementation of such gamesshould include an underlying fairness property for the players. This ischallenging, however, in cases where players, distributed over widegeographic areas, participate in a game together.

In the client-server model, an authoritative game server is set up andall players or clients contact this game server to play the game againstone another. The game server keeps track of the global state of thegame. Players send their actions to the game server in messages referredto as action messages. The game server then processes the actions insequence, changes the global state, and notifies players of the effectsof their actions in messages termed state update messages or simplyupdate messages. The state change that is communicated to the playersmay lead to more action messages being sent to the game server. The onlycommunication in the system is between the game server and players.Players themselves do not send messages to one another, neither do theyplay any active role in deciding the ordering of actions in the game.Because of the real-time nature of online multi-player games, themajority of action and state update messages are sent over UDP; only afew messages are sent over TCP and only at game start-up. Because ofthis, applications have built-in mechanisms to handle message loss. Forexample, messages contain absolute location of objects instead ofrelative ones, therefore, there is no dependency on previous messages incase they are lost.

Much of the focus on improving real-time, online multi-player games ison how to reduce player experienced response time. For timely stateupdates at player consoles, dead reckoning is commonly used tocompensate for packet delay and loss. For client-server based firstperson shooter games, Y. W. Bernier, “Latency Compensation Methods inClient/Server In-game Protocol Design and Optimization,” in Proc. ofGame Developers Conference'01, 2001, URL:http://www.gdconf.com/archives/proceedings/2001/prog\_papers.htmldiscusses a number of latency compensating methods at the applicationlevel which are proprietary to each game. These methods are aimed atmaking large delays and message loss tolerable for players but do notconsider the problems introduced by varying delays from the server todifferent players.

Using the current best-effort Internet, players can experience erraticgame progress that often prevents a player from responding effectivelyor appropriately. This can lead to player frustration, especially if thegaming environment is competitive. In addition, because the game serveris in charge of updating global states, and the network delay from thegame server to different players is different, players may receive thesame state update at different times. Furthermore, players' actionmessages can also take different times to reach the game server,therefore unfairness in processing player action messages can be createdat the game server. A player further away from the game server orconnected to the server through congested or slower links will sufferfrom longer message delay. Because of this, even fast reacting playersmay not be given credit for their actions, leading to an unfairadvantage for players with small message delays.

SUMMARY OF THE INVENTION

The Fair-Order Service of the present invention delivers action messagesto the server as soon as it is feasible. Because action messages fromdifferent players exhibit different reaction times with respect to anupdate message, the Fair-Ordering Service executed at the serverdynamically enforces a sufficient waiting period on each action messageto guarantee the fair processing of all action messages. In reality, thewaiting period at the server is bounded because of the real-time natureof interactive games. The algorithms that offer Fair Ordering Servicetake into consideration delayed and out-of-order action messages. Whenaction messages corresponding to multiple update messages areinterleaved, the Fair-Ordering Service matches the action message to theappropriate update message. It accomplishes this by maintaining a windowof update messages and using the reaction times for an action messagefor each of the update messages in the window. This enables statechanges at the game server to be performed with fairness to all theplayers. The Fair-Order Service invention is based on a framework thatuses a proxy architecture making it transparent to any specific gameapplication. The service is well suited to client-server based, onlinemulti-player games, where a fair order of player actions is critical tothe game outcome.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be obtainedfrom consideration of the following detailed description of theinvention in conjunction with the drawing, with like elements referencedwith like references, in which:

FIGS. 1(a) and (b) show exemplary embodiments of a distributed gameenvironment;

FIG. 2 shows an example of a state and its transition;

FIG. 3 illustrates an exemplary message exchange between server andplayers in accordance with the present invention.

FIG. 4 shows a fair order message delivery for state transitions shownin FIG. 2;

FIG. 5 shows an exemplary algorithm for fair-order message queuing inaccordance with the present invention;

FIG. 6 shows an example where messages arrive after their wait timeout;

FIG. 7 shows an exemplary algorithm for fair-order message dequeuing inaccordance with the present invention;

FIG. 8 shows an example message sequence illustrating inconsistent viewsof a game between players;

FIG. 9 shows a message sequence illustrating the fair-order messagedelivery service of the present invention; and

FIG. 10 shows another message sequence illustrating the fair-ordermessage delivery server of the present invention with out-of-ordermessage reception; and

FIG. 11 is an exemplary embodiment of a proxy device used in connectionwith the present invention.

DETAILED DESCRIPTION

The above mentioned unfairness problem is the focus of the presentinvention. Assuming that update messages are delivered to players at thesame physical time, a fair order of message delivery would be one whereaction messages in response to these update messages are delivered tothe server in the order in which they are produced by the players inphysical time. This ensures that a player who reacted first to an updatemessage by sending an action message will influence the state of thegame before a player who reacted later. One earlier work onfair-ordering of action messages, the Sync-MS service by Y. Lin, K. Guo,and S. Paul, “Sync-MS: Synchronized Messaging Service for Real-TimeMulti-Player Distributed Games,” in Proc. of 10th IEEE InternationalConference on Network Protocols (ICNP), November 2002, is based on afairness definition for both state update messages and action messages.The Sync-MS service consists of two parts, Sync-out and Sync-in, whereSync-out delivers each state update message from the server to allplayers at the same physical time, and Sync-in at the server processesaction messages in the order of the physical time they are sent. But inorder to deliver messages to all the players at the same physical time,two main assumptions are made: (i) the clocks at all the players aresynchronized and all these clocks are synchronized with the server clockas well, and (ii) the one-way delay from the server to each of theplayers can be accurately estimated. The above assumptions are requiredbecause an attempt is made to order action messages according to thephysical time in which the players produce these messages. Further, thiswork does not consider the interleaving that may happen between actionmessages corresponding to multiple update messages and the effect ofsuch interleaving on the state of the game that is maintained at theserver.

Without making the above assumptions, the same fair-order deliveryeffect can be achieved by delivering the action messages to the serverin the order of increasing reaction time which is the time between thereception of an update message at a client and the sending of an actionmessage in response to the update message. This removes the need todeliver update messages to all the players at the same physical time.Based on this idea, a novel network service is disclosed calledFair-Ordering Service, designed for client-server based, distributed,multi-user real-time applications such as online multi-player games. Itaddresses the issue of player action message fairness based on playerreaction time. Note that the Fair-Ordering Service does not attempt toshorten network delays between the server and players but provides aframework that ensures fairness to players even when network delays arelarge and variable. Delay reductions could come from advances in CPU,link speed or game specific features, and therefore is orthogonal to aservice that provides fair order delivery.

Unlike existing techniques that use bucket synchronization mechanismsthat depend on imposing a worst case delay on action messages, theFair-Order Service of the present invention delivers action messages tothe server as soon as it is feasible. Because action messages fromdifferent players exhibit different reaction times with respect to anupdate message, the Fair-Ordering Service executed at the serverdynamically enforces a sufficient waiting period on each action messageto guarantee the fair processing of all action messages. In reality, thewaiting period at the server is bounded because of the real-time natureof interactive games. The algorithms that offer Fair Ordering Servicetake into consideration delayed and out-of-order action messages. Whenaction messages corresponding to multiple update messages areinterleaved, the Fair-Ordering Service matches the action message to theappropriate update message. It accomplishes this by maintaining a windowof update messages and using the reaction times for an action messagefor each of the update messages in the window. This enables statechanges at the game server to be performed with fairness to all theplayers.

The Fair-Order Service invention is based on a framework that uses aproxy architecture making it transparent to any specific gameapplication. The service is well suited to client-server based, onlinemulti-player games, where a fair order of player actions is critical tothe game outcome. Examples of such games include first person shootergames like Quake, R. Swamy, “idSoftware Releases Quake 1 Source CodeUnder the GPL,” URL: http://linuxtoday.com/stories/14111/html., andreal-time role playing games such as Dark Age of Camelot, MythicEntertainment, “Dark Age of Camelot,” URL:http://www.darkageofcamelot.com. The game framework is clearly definedand its applicability in practice is illustrated through examples.

Message Exchange Framework for Distributed Games

As discussed, the present invention relates to a network-based servicefor distributed multi-player games called Fair-Ordering Service. Theservice guarantees fair-ordering for action messages that are receivedat the server from all players in the game. The client-server basedsystem consists of a game server 12 and a number of game players 14(e.g., player devices) distributed over a network 10 as shown, forexample, in FIG. 1(a). The server sends state update messages to theplayers to inform them of the latest state of the game. Each playerprocesses the update messages, displays the current state of the gameand produces action messages based on the reaction of the human playeron the current state. Multiple action messages may be sent by a playerin response to one update message.

In order to perform the fair-ordering service, we introduce proxies forthe server and the players, referred to as server proxy 16 and playerproxy 18, respectively (FIG. 1(b)). The proxies could be co-located withthe applications themselves, be part of the application or they could beone or more separate elements. Accordingly, when referring to proxy inthe specification and the claims of the application it is understoodthat the proxy refers generally to the functionality of the inventionand that the location of the proxy may be in any one of the abovelocations. As shown in FIG. 1(b), both update and action messages areintermediated through the proxies. We assume that the network delaybetween proxies and their respective server or player is negligible.

The invention takes into account the most general distributedenvironment where (1) the underlying network transport may not guaranteeany desired ordering of message delivery from multiple sources, (2)messages from the same source may reach their common destination out oforder, or may get lost in transport, and (3) the individual players andthe game server do not have their clocks synchronized.

As will be explained in greater detail herein, the server proxy receivesupdate messages from the game server, tags them with message numbers andsends them to the player proxies. It receives action messages from theplayer proxies, orders them to ensure fairness based on the additionalinformation with which the player proxies augment the action message,and delivers them to the game server. The player proxy receives updatemessages from the server proxy and delivers them to the players. In theother direction, it tags the action messages sent by the players withthe appropriate information as described herein, and sends them to theserver proxy. Notice that in the described exemplary embodiment theproxies are completely transparent to specific games; that is, they arenot aware of the semantics of a particular game.

State and State Transitions

The state of a game at the server is defined to be a set of objects andtheir positions. A state transition takes place when there is a changein the set of objects or the positions of the objects. State updatemessages are sent by a server periodically to the players either toinform the player of a state transition or simply the current positionsof the objects. The interval between two consecutive update messagessent by the server is typically 40 ms for real-time video display at 25frames per second. For simplicity, the examples set forth herein onlyillustrate state transitions where there is a change in the set ofobjects.

FIG. 2 assists in illustrating the definition of state transition. Theinitial state of the game S₁ shows three aircraft AC₁, AC₂ and AC₃. Anupdate message UM₁ is sent to the players with this state information attime U₁. The next state S₂ shows only aircraft AC₁ and AC₃. AC₂ has beenremoved because of an action message that the server received from someplayer. An update message UM₂ is sent at time U₂ to notify the playersof the state transition. State S₃ shows aircraft AC₁ and AC₄. AircraftAC₃ has been removed and aircraft AC₄ has been included. A correspondingupdate message is also sent to the players. Thus, a state transitioninvolving change of objects, not positions, may be due to one of thefollowing reasons: (a) removal of objects, (b) inclusion of objects, and(c) removal as well as inclusion of objects. A state change always leadsto an update message being sent.

Fair-Order

Let us now examine the message exchanges between the server and theplayers and their effect on the state of the game. FIG. 3 shows a timingdiagram of an instance of message exchange between the server and theplayer P_(j). Let U_(i) denote the server's local time at which theserver sends an update message UM_(i). Player P_(j) receives UM_(i) atits local time R_(j) ^(i). After receiving an update message, the playeracts on it, which in turn generates an action message. We refer to theduration between reception of an update message and transmission of anaction message by a player as reaction time. AM_(jk) ^(i) denotes thek^(th) action message sent by player j at its local time A_(jk) ^(i)after acting on UM_(i) from the server. Let δ_(jk) ^(i)=A_(jk)^(i)−R_(j) ^(i) denote the corresponding reaction time. For each updatemessage, the Fair-Ordering Service delivers player action messages(corresponding to that update message) to the server in an increasingorder of the reaction times.

Consider FIG. 3 again and assume the message exchanges are between theproxies for both the server and player P_(j). Let → denote the deliveredbefore relationship between two messages. Then, fair-order delivery willneed to satisfy the following three conditions.

Fair Order Conditions

1) For update message UM_(i) and player P_(j), AM_(jk) ^(i)→AM_(j(k+1))^(i) for all k, and l>0. That is, all action messages produced by aplayer in response to an update message are delivered to the server inthe order in which they were produced, and

2) For update message UM_(i) and players P_(j) and P_(n), AM_(jk)^(i)→AM_(nl) ^(i), for all j, k, l and n≠j, if (δ_(jk) ^(i)=A_(jk)^(i)−R_(j) ^(i))<(δ_(nl) ^(i)=A_(nl) ^(i)−R_(n) ^(i)). That is, actionmessages from two different players corresponding to the same updatemessage are delivered in increasing order of reaction times, and

3) For update messages UM_(a) and UM_(a+x), x>0, AM_(jk) ^(a)→AM_(nl)^(a+x) for all j, k, n and l. That is, all action messages produced inresponse to an update message from all players are delivered to theserver before delivering action messages that are produced in responseto an update message that was sent later.

In an ideal distributed game environment where all players have asynchronized clock and message delivery over the network takes the sameamount of time for every player, fair-order can be achieved if theaction messages from the players are ordered based on the physical timesat which they are generated. It is easy to see that in this idealsituation, such ordering would result in the action messages beingordered in an increasing order of reaction times. In practice, however,neither the players' clocks are synchronized nor the delay in messagedelivery is the same or even known a priori. The fair-orderingrequirements enumerated above provide fair processing of the actionmessages without these assumptions. In essence, for game applications itmakes sense to award a player with the fastest reaction time, and theFair-Ordering Service ensures that.

Referring to FIG. 4, an example of the Fair-Ordering Service inaccordance with the present invention is illustrated. The fair-ordermessage distribution and the state changes happen in the server andplayers P₁ and P₂. The server and player proxies (not shown in the-Figure) work transparently to the server and the players to ensurefair-ordering of the messages. When the state of the game is S₁, updatemessage UM₁ is sent by the server and received by both players. Playersmay receive UM₁ at different instants of local time (that is, R₁ ¹≠R₂ ¹)due to variability in network conditions. As noted previously, they runindependent clocks that may neither be synchronized with each other norwith the game server. P₁ sends an action message AM₁₁ ¹=<Remove AC₂>,which is received at the server proxy with reaction time δ₁₁ ¹. P₂ alsosends an action message AM₂₁ ¹=<Remove AC₂> with reaction time δ₂₁ ¹>δ₁₁¹. The server proxy receives both action messages, and inspection of thereaction times reveals that player P₁ has acted on state S₂ of the gamequicker than player P₂ . Therefore, the action <Remove AC₂> isattributed to P₁, not to P₂, regardless of the relative arrival order ofAM₁₁ ¹ and AM₂₁ ¹. With Fair-Ordering Service, the server delivers AM₁₁¹ from P₁ to the server first. Note that FIG. 4 depicts the deliveryinstances of action according to fair order. The server acts on thismessage and AC₂ is removed. This action message changes the state to S₂and update message UM₂ is sent at time U₂. When the action message AM₂₁¹ from P₂ is delivered and processed at the server, it will be done withrespect to state S₂. As AC₂ has already been removed and is not part ofstate S₂ , this action message leads to no operation being performed bythe server. P₁ collects credit for removing AC₂, but P₂ does not,therefore fairness is ensured.

Now assume that UM₂ reaches the players and they send action messagesAM₁₁ ₂=<Remove AC₃, Add AC₄> and AM₂₁ ²=<Remove AC₁>, respectively withreaction times δ₁₁ ²<δ₂₁ ². Again with Fair-Ordering Service, AM₁₁ ₂ isprocessed first, AC₃ is removed and AC₄ is added. The state is changedto S₃ and update message UM₃ is sent at time U₃. AM² ₂₁ processed nexton state S₃ and AC₁ is removed and the state changes to S₄ and updatemessage UM₄ is sent. Notice the sequence of state changes is reflectedin FIG. 2. In the following section we describe a suite of algorithmsthat guarantees fair-order delivery of action messages to the server.

Fair-Ordered Message Delivery Algorithms

When a server sends the i^(th) update message UM_(i) to the players, theserver proxy records the sending time U_(i), and tags it with the updatemessage number i or a function thereof. Similarly, when the proxy forplayer P_(j) receives this message, it records in R_(j) ^(i) thereception time for this message. Further, when the k^(th) action messageis sent at time A_(jk) ^(i) in response to the i^(th) update message,the player proxy uses A_(jk) ^(i) to calculate δ_(jk) ^(i). The playerproxy sends the action message along with the following informationtagged to the message: (a) the update message number, i corresponding tothis action message, (b) the reaction time δ_(jk) ^(i), and (c) theN_(jk) ^(i) action message number, where all of the above may also befunctions or some other representation corresponding the values to beindicated. The action messages are numbered in an increasing orderstarting from 1 and the numbering scheme spans different updatemessages. That is, if the last action message from a playercorresponding to update message UM_(i) is numbered m, the first actionmessage from the same player corresponding to update message UM_(i+1)will be numbered m+1. This numbering system is used in deliveringmessages in order. Thus, update message UM_(i) from the server will betagged with i at the proxy server and action message AM_(jk) ^(i) fromplayer P_(j) will be tagged with the three tuple (i,δ_(jk) ^(i),N_(jk)^(i)). As would be understood, other numbering systems used to conveysimilar information may also be used. Because message number N_(jk) ^(i)is used to deliver action messages from the same player in sequence, wedo not need to consider it until we consider action messages that arriveout of order.

At the server proxy, the expected round-trip time (excluding anyreaction time at the player, of course) to each of the players or playerproxies is computed using some standard algorithm such as for TCP. Wedenote by W_(j) the wait timeout value for player P_(j). The calculationof the round-trip time is independent of the message delivery algorithm.Let rtt_(j) be the expected round-trip time from the server proxy toproxy for player P_(j). An exponential averaging algorithm can be usedto update the rtt based on the round-trip that is seen for a particularmessage as follows: rtt_(new)=(1−α)×rtt_(old)+α×rtt_(current), wherertt_(new) is the updated rtt, rtt_(old) is the rtt that was calculatedbefore, rtt_(current) is the rtt for the current message and a is anexponential averaging factor where 0<α<1. In order to account forvariances in round-trip time, the maximum amount of time that the serverproxy will wait before timing out on an action message from a playerwill be some multiple of the round-trip time. Let W_(j) denote this waittimeout value for player P_(j). Thus, W_(j)=b×rtt_(j), where b>1 is someconstant.

When an action message is received at the server proxy, it is queued tobe delivered to the game server; before it is queued, the followingparameters are computed: (a) the position in the queue where thismessage should be inserted and (b) the local time at which the messageis to be delivered to the game server. Every time an action messagearrives, this arrival can lead to the re-computation of both the currentposition and the delivery time of messages in the queue. The relativeposition of the messages (i.e., position with respect to on another)already in the queue will not change, but their absolute positions maychange because the arriving action message may be inserted anywhere inthe queue. The delivery time of the messages may change and this changewill always lead to the delivery time being shortened. These areproperties of the fair-ordering message delivery algorithm describedbelow. Note that the definition of fair-order delivery is only valid formessages arriving within their wait timeout values. An approach to dealwith messages with network delay larger than their wait timeouts isdiscussed herein.

Position of a Message in the Delivery Queue

When an action message AM_(jk) ^(i) arrives at the server proxy, it isinserted into the delivery queue and the location where it is insertedis based on the values i and δ_(jk) ^(i). The delivery queue is keptsorted based on the two tuple (i,δ) with the key i first and then thekey δ. Thus, an action message with the tuple (2, 3) will be positionedbefore another action message with the tuple (2, 4) and the actionmessage with the tuple (2,4) will be positioned before another actionmessage with the tuple (3, 2). This means, the messages are sorted inthe ascending order of their corresponding update message ids and withinthe set of action messages corresponding to an update message, they aresorted in the ascending order of the reaction times. Note that when anaction message arrives, it can be inserted anywhere in the queue and therelative positions of the existing messages in the queue do not change.The message delivery algorithm has the following main property.

Property 1: If the delivery queue is sorted based on the tuple (i, δ)with the key i first and then the key δ, then fair-order delivery isensured if the messages are delivered in the order they are found in thedelivery queue.

The above property holds because sorting and delivering messages basedon (i, δ) satisfies all three conditions of fair-ordering. Sorting themessages in the order of the update message ids (e.g., i) ensures thatfair-order delivery Condition 3 is satisfied. In addition, furthersorting the messages corresponding to an update message, using reactiontimes ensures fair-order Condition 2 and Condition 1. Note that theaction message number (N) carried by the action message could have beenused to ensure Condition 1, but it is not necessary since sorting actionmessages according to reaction times trivially ensures Condition 1.

Computation of Delivery Time of a Message

When an action message corresponding to an update message arrives at theserver proxy, the algorithm shown in FIG. 5 is executed to insert themessage into the delivery queue. The first step is to compute thedelivery time D(M_(k)) of the action message M_(k) to the game server.Delivery time is computed such that any action message that may arriveout of fair-order at the server proxy is delivered to the game server infair-order. In order to achieve this, messages may be queued in theserver proxy and delivered according to the delivery time. We will showlater (in Properties 2 and 3) that execution of step 2 of the algorithmdoes not modify the relative order of the messages that are already inthe fair-ordered delivery queue. The delivery time of the existingmessages are recomputed in step 4 only to deliver them earlier thantheir previously computed delivery time (refer to Property 3 herein).

We detail the procedure to compute the delivery time of a message in thefollowing three sections. In a first section we assume that messagesarrive at the server proxy in the order in which they are sent by theplayer and within their wait timeouts. A next section augments theprevious section with messages arriving out of order but within theirwait timeouts and a later section presents the most general case whenmessages do not arrive within their wait timeouts.

1) Messages arrive in order and within their wait time-out: Consider aset of action messages that have been received at the server proxy inresponse to update message UM_(i) and have been fair-ordered and put inthe delivery queue according to their reaction times. Let these actionmessages in the fair-ordered queue be M₁,M₂, . . . , M_(n). Let D(M_(k)) denote the delivery time of action message M_(k) and P(M₁,M₂, .. . ,M_(n)) denote the set, which represents the union of all theplayers who sent messages M₁,M₂, . . . ,M_(n). Let δ_(k) denote thereaction time for message M_(k). Since M_(k)'s are fair-ordered, δ₁≦δ₂≦. . . ≦δ_(n). Let T denote the set of all players. Then, the earliestpossible delivery time for a message in the queue, based on messagesarrived so far, will be as follows.

Definition 1: Computation of delivery time with in order message arrivaland within their wait timeouts: Delivery time of message M_(k),1≦k≦n, inthe fair-ordered queue is D(M_(k))=U_(i)+max_({jεT−P(M) _(k) _(,M)_(k+1) _(, . . . ,M) _(n) _()}){W_(j)}+δ_(k).

Note that ordering the messages and delivering them according to theirreaction times will ensure fair-ordering delivery of messages only if itis guaranteed that when an action message corresponding to an updatemessage is delivered, no other action message corresponding to the sameupdate message with a smaller reaction time may be in transit. Considermessage M₁. The update message UM_(i) corresponding to this actionmessage was sent at time U_(i). The reaction time for this message isδ₁. Since we assumed messages arrive within wait timeout, if a messagefrom another player P_(j) corresponding to update message UM_(i) with areaction time smaller than δ₁ is to arrive at the server proxy, it needsto arrive by time U_(i)+W_(j)+δ₁. Considering all players, for a messagewith a reaction time smaller than δ₁ to arrive from any player(including P(M₁)), it needs to arrive by timeU_(i)+max_({jεT}){W_(j)}+δ₁. But in order arrival ensures that actionmessages arrive at the server proxy in the order in which they are sent.This means no action messages from P(M₁,M₂, . . . ,M_(n))can be receivedwith a reaction time smaller than δ₁ given that action messages from allthese players have been received with reaction times larger than orequal to δ₁. That means, only players from whom no action message hasbeen received need to be considered. Thus, D(M₁)=U_(i)+max_({jεT−P(M) ₁_(,M) ₂ _(, . . . ,M) _(n) _()}){W_(j)}+δ₁. In general, for M_(k), noaction messages from P (M_(k),M_(k+1), . . . ,M_(n)) can be receivedwith a reaction time smaller than δ_(k) given that action messages fromall these players have been received with reaction times larger than orequal to δ_(k). Note that in this case, it is possible that anotheraction message is received from P(M₁,M₂, . . . ,M_(k−1)) with a reactiontime smaller than δ_(k). Then, there are only two sets of players needto be considered. One set is the players from whom no action messageshave been received which are T−P(M₁,M₂, . . . ,M_(n)), and the other isP(M₁,M₂ , . . . ,M_(k−1)). This justifies the above definition.

It is necessary to ensure that the delivery times of messages computedusing the above definition are consistent with the order in which theaction messages are ordered in the delivery queue. If the delivery timessatisfy this we call it a feasible delivery order. The delivery timecomputation defined above does lead to a feasible delivery order asargued below.

Property 2: Property of delivery time where messages arrive in order andwithin their wait timeouts: Message delivery time sequence D(M₁),D(M₂),. . . ,D(M_(n)), is a feasible delivery order.

The above property holds because of the following reasoning. SinceM₁,M₂, . . . ,M_(n) are fair-ordered, δ₁≦δ₂≦ . . . ≦δ_(n) holds. Alsonotice that max_({jεT−P(M) ₁ _(,M) ₂ _(, . . . ,M) _(n)_()}){W_(j)}≦max_({jεT−P(M) ₂ _(,M) ₃ _(, . . . ,M) _(n) _()}){W_(j)}≦ .. . ≦max_({jεT−P(M) _(n) _()}){W_(j)}

Therefore, D (M₁)≦D(M₂)≦ . . . ≦D(M_(n)). Thus the property follows.

The above property illustrates that given action messages, it isfeasible to achieve fair-ordered delivery at the server by queuing themin fair-order at the server proxy and delivering them to the serveraccording to their respective delivery times.

Definition 2: Recomputation of delivery time where messages arrive inorder and within their wait timeouts: Suppose an action messageM_(p),p>n,δ_(k)≦δ_(p)≦δ_(k+1), is inserted into the delivery queueM₁,M₂, . . . ,M_(n) conforming the fair-order. Then the delivery timesof M₁,M₂, . . . , M_(p−1) are recomputed as,D^(new)(M_(m))=D(M_(m))−β_(m),1≦m<p where β_(m)=max_({jεT−P(M) _(m)_(,M) _(m+1) _(, . . . ,M) _(n) _()}){W_(j)}−max_({jεT−P(M) _(m) _(,M)_(m+1) _(, . . . ,M) _(k) _(,M) _(p) _(,M) _(k+1) _(,M) _(n)_()}){W_(j)}. For p≦m≦n, D(M_(m)) does not change, thereforeD^(new)(M_(m))=D(M_(m)).

Note that the computation of the delivery time of M_(p) with reactiontime δ_(p), and recalculation of delivery times of M₁,M₂, . . . ,M_(n)are straightforward from Property 1 and Definition 1. Sinceδ_(k)≦δ_(p)≦δ_(k+1), according to Property 1, M_(p) is inserted betweenM_(k) and M_(k+1) in the delivery queue, and the new message orderbecomes M₁,M₂, . . . ,M_(k), M_(p),M_(k+1), . . . ,M_(n). Since themessage order has changed, following Definition 1, D^(new)(M₁) wecompute the new delivery times for message M₁, 1≦l≦n+1, as follows:${D^{new}\left( M_{1} \right)} = {U_{i} + {\max\limits_{\{{j \in \quad{T - {P{({M_{1},M_{2},\ldots\quad,M_{k},M_{p},M_{k + 1},\ldots\quad,M_{n}})}}}}\}}\left\{ W_{j} \right\}} + \delta_{1}}$${D^{new}\left( M_{2} \right)} = {U_{i} + {\max\limits_{\{{j \in \quad{T - {P{({M_{2},\ldots\quad,M_{k},M_{p},M_{k + 1},\ldots\quad,M_{n}})}}}}\}}\left\{ W_{j} \right\}} + \delta_{2}}$⋮${D^{new}\left( M_{k} \right)} = {U_{i} + {\max\limits_{\{{j \in \quad{T - {P{({M_{k},M_{p},M_{k + 1},\ldots\quad,M_{n}})}}}}\}}\left\{ W_{j} \right\}} + \delta_{k}}$

It can be observed that when a newly arrived message is inserted intothe delivery queue, the delivery times for messages behind it are notchanged. The delivery times for messages ahead of it either shorten ordo not change. This is because the set of players whose wait timeoutvalues are considered in the formula decreases by one, i.e., P(M_(p)).The algorithm, as it is specified, requires that the delivery time ofall messages ahead of the newly arriving message be recalculated everytime a message arrives. Arrival of every message could potentiallyshorten the delivery time of every message ahead of it and hence makethe game progress faster. But this computation is not required tomaintain feasible delivery order. If it is observed that the overhead ofrecomputing the delivery time is high, the recalculation could beperformed after the arrival of a number of messages (rather than everymessage). This would require information to be kept about all themessages that arrive within two such recalculations and apply thisinformation when recalculation is performed. The tradeoff betweenprocessing overhead and delayed message delivery can be adjusted byproperly choosing the number of message arrivals to wait beforerecalculation. The delivery times of the action messages ahead of it canbe incrementally updated as defined in Definition 2.

Property 3: Property of recomputed delivery time when messages arrive inorder and within their wait timeouts: If the message delivery timesequence D(M₁),D(M₂), . . . ,D(M_(n)) is a feasible delivery order and anewly arrived message M_(p) is fair-orderly inserted between M_(k) andM_(k+1), then the sequence of recomputed message delivery times,D^(new)(M₁),D^(new)(M₂), . . . ,D^(new)(M_(n)),D^(new)(M_(n+1)), remainsa feasible delivery order.

The above property holds because of the following reasoning. Sincemessage delivery time D(M_(r)),1≦r≦n, is in a feasible delivery order,we know that D(M₁)≦D(M₂)≦ . . . ≦D(M_(k))≦D(M_(k+1))≦ . . . ≦D(M_(n)).We also know that D^(new)(M_(m)),1≦m<p, are the only deliver times thatmay have changed and may be different from D(M_(m)),1≦m<p due to thefair-ordered insertion. Since D^(new)(M_(m)),1≦m≦p are computed usingDefinition 1, we know from Property 2 that D^(new)(M₁)≦D^(new)(M₂)≦ . .. ≦D^(new)(M_(k))≦D^(new)(M_(p)). Since D^(new)(M_(m)),k+1≦m≦n are thesame as D(M_(m)),k+1≦m≦n, we also know thatD^(new)(M_(k+1))≦D^(new)(M_(k+2))≦ . . . <D^(new)(M_(n)). Sincemax_({jεT−P(M) _(p) _(,M) _(k+1) _(, . . . ,M) _(n)_()}){W_(j)}≦max_({jεT−P(M) _(k+1) _(, . . . ,M) _(n) _()}){W_(j)}, wenote that D^(new)(M_(p))≦D^(new)(M_(k+1)) and that D(M_(k+1))=D(M_(k)).Thus we conclude that D^(new)(M₁)≦D^(new)(M₂)≦ . . .≦D^(new)(M_(k))≦D^(new)M_(p)≦D(M_(k+1))≦ . . . ≦D(M_(n)). This meansthat the feasible delivery order is still maintained for the recomputedmessage delivery times.

The above property establishes the fact that if the server proxy keepsthe message delivery queue always sorted according to the fair order,and recomputes the delivery times of the affected messages due to theinsertion of a newly arrived message, the fair-order delivery ofmessages to the game server can be ensured. 2) Messages arrive out oforder but within their wait timeouts: Let us now consider the situationwhere action messages from a player can arrive at the server proxy outof order. The action message numbers carried in the action messages arenow used to (1) order the messages from a specific player and (2) when amessage arrives determine whether all earlier messages that were sent bythe same player have already arrived. When messages arrive, they arefair-ordered in the delivery queue based on their reaction times asbefore, but now, delivery times are computed accounting for the factthat messages may arrive out of order.

Assuming that the delivery queue contains messages M₁,M₂, . . . ,M_(n)in that order, let Q(M₁,M₂, . . . ,M_(n)) denote the subset of messageswithin M₁,M₂, . . . ,M_(n) which are sequenced in the sense that allmessages from the players P(Q(M₁,M₂, . . . ,M_(n))) that were sentbefore have already been received and have either (a) been delivered tothe server or (b) been placed in the delivery queue. Then the deliverytimes will be computed as follows.

Definition 3: Computation of delivery time with messages arriving out oforder but within their wait timeouts: Delivery time of messageM_(k),1≦k≦n, in the fair-ordered queue isD(M_(k))=U_(i)+max_({jεT−P(Q(M) _(k) _(,M) _(k+1) _(, . . . ,M) _(n)_())}){W_(j)}+δ_(k). This definition follows similar reasoning asDefinition 1. The only difference here is that the delivery time ofmessage M_(k) must consider the possible arrival of out of ordermessages with smaller reaction times than δ_(k) for all messages thatare not sequenced.

The following property ensures that delivery times, as computed above,lead to a feasible delivery order.

Property 4: Property of delivery time when messages arrive out of orderbut within their wait timeouts: Message delivery time sequenceD(M₁),D(M₂), . . . , D(M_(n)), is a feasible delivery order.

This property can be shown to hold following reasoning similar to thosefor Property 2. The delivery times of the messages after the insertionof the new message can be computed using procedure similar to theprevious case. Further, it can be shown that the newly computed deliverytimes will satisfy a feasible delivery order using reasoning similar tothat used for Property 3.

3) Messages do not arrive within their wait timeout: Let us now considerthe situation when messages may arrive after their wait timeout.Consider the example shown in FIG. 6 with two players P₁ and P₂. Thesequence numbers of messages are shown below the messages. In FIG. 6(a),the delivery queue is shown with messages M₁, M₃ and M₄ from P₁ and M₂from P₂. Assume that the message from P₁ with the sequence number 101has not arrived yet. Consider message M₂ from P₂ With respect to thismessage, M₃and M₄ are not sequenced according to the definition of Qgiven previously.

Assume that the delivery time for M₁ is reached before the message withsequence number 101 from P₁ arrives. This means, the wait timeout valuefor this message has been exceeded. Message M₁ will be delivered and themessage with sequence number 101 will be marked late and delivered tothe game server immediately when it arrives. The server proxy could alsodrop late messages. However, as the server proxy is not aware of gamesemantics, it may be more appropriate for the server proxy to deliverthe message to the game server and let the game server decide how toprocess it.

When M₁ is delivered, messages M₃ and M₄ will become sequenced withrespect to M₂ as shown in FIG. 6(b). This means, the delivery time of M₂needs to be recomputed. That is, when messages can arrive after theirwait time-outs, delivery times of messages in the queue need to beupdated even when messages are delivered in addition to being updatedwhen messages arrive (for the cases when messages arrive within theirwait timeout, as described in previous sections, delivery times have tobe updated only when messages arrive). In this case, the computation ofdelivery times is exactly as indicated in Definition 3 when messages getdelivered as well as when messages arrive. Property 4 holds for thiscase as well, except when the message at the head of the queue isdelivered, recomputation of delivery time is needed for all messages inthe queue. We add the dequeuing algorithm presented in FIG. 7 whenmessages do not arrive within their wait timeout. When a message withsequence number 101 arrives, it will be tagged as a late message anddelivered immediately to the game server. As it had already been markedas late and delivery times of the messages in the queue had been updatedbased on this, no recomputation of delivery times is needed at thispoint.

4) Correlation of action message delivery time: So far we have computedthe delivery time of action messages corresponding to an update messageUM_(i) in isolation, that is, without considering the delivery times ofthe action messages corresponding to update message UM_(i−1). Thedelivery queue is kept sorted based on the tuple (i,δ). Action messagesare delivered to the game server in this order. That is, all actionmessages corresponding to update message UM_(i−1) are delivered beforeany action message corresponding to update message UM_(i) is delivered.This correlated decision overrides the delivery times computed for anaction message considering the corresponding update message inisolation.

The game application must define what all action messages correspondingto an update message signify. Action messages corresponding to an updatemessage can arrive at any time and assuming that players can send anynumber of action messages per update message, a determination must bemade when not to accept any more action messages corresponding to anupdate message. Let us assume that this decision is made based on sometechnique determined by the game application. When this determination ismade for update message UM_(i−1) let us assume that the delivery timecomputed for the last action message L_(i−1) corresponding to UM_(i−1)in the delivery queue to be t_(i−1). Any action message corresponding toUM_(i−1) that arrives after L_(i−1) has been delivered will be dropped.Of course, any action message corresponding to UM_(i−1) that arrives atthe server proxy before L_(i−1) is delivered, and is deemed to bedelivered before L_(i−1), will be delivered. Let D^(i)(M₁,),D^(i)(M₂), .. . ,D^(i)(M_(n)) denote the delivery times of messages M₁,M₂, . . .,M_(n) that are in the delivery queue and correspond to update messageUM_(i). Then, the delivery time of message M_(k),1≦k≦n, as computed inthe previous section must be modified as:D^(i)(M_(k))=max{t_(i−1),U_(i)+max_({jεT−P(Q(M) _(k) _(,M) _(k+1)_(, . . . ,M) _(n) _())}){W_(j)}+δ_(k)}. This ensures that all actionmessages corresponding to update message UM_(i−1) are delivered beforeany action message corresponding to update message UM_(i) is delivered.Note that the delivery times computed above can change due to bothmessage arrivals and message deliveries. The change could be (a) due toa change in t_(i−1), which could be due to the arrival or delivery of anaction message corresponding to update message UM_(i−1) or earlierupdate messages, or, (b) due to an arrival of an action messagecorresponding to update message UM_(i) which will lead to a change inthe second component on which maximum is computed.

Fairness Among Players with Inconsistent Views

The fair-ordered message delivery algorithm described previously assumesthat when an action message is sent by a player proxy, it carries thetuple (i,δ) where i is the update message id of the most recent updatemessage UM_(i) received at the player. In our discussion of thealgorithm, we implicitly assumed that all players receive UM_(i), updatetheir states and then send the action messages corresponding to UM_(i).In practice it may so happen that a new update message UM_(i+1), sent bythe server does not reach a set of players or is delayed compared to therest of the players. Therefore, the players with the most up-to-dateinformation send all their action messages tagged with update message idi+1 by the player proxies, whereas the remaining players send actionmessages tagged with the previous update message id i. This situation,where action messages and update messages cross each other, may lead tounfairness among the players. The unfairness arises due to theinconsistency in the view of the game that each player possesses. Wefirst describe the problem with the help of an example and then describethe steps taken in the fair-ordered message delivery system of theinvention to overcome this.

Consider the same example shown in FIG. 2, with a slightly differentupdate and action message sequence than the one in FIG. 4. The messagesequence is shown in FIG. 8. Assume that when UM₁ is received, playersP₁ and P₂ send action messages AM₁₁ ¹=<Remove AC₂> and AM₂₁ ¹=<RemoveAC₂>, respectively, with δ₂₁ ¹>δ₁₁ ¹. AM₁₁ ¹ gets delivered (when itsdelivery time is reached) by the server proxy to the game server. Theserver changes state to S₂ and sends update message UM₂. Assume that UM₂reaches P₂ but does not reach P₁. At this time, the state according toP₁ is S₁ and the state according to P₂ is S₂. Assume now that both P₁and P₂ send action messages AM₁₂ ¹=<Remove AC₃, Add AC₄>, and AM₂₁²=<Remove AC₃, Add AC₄>. Note that AC₃ is part of both S₁ and S₂. Theaction message from P₁ will carry the tuple (1,δ₁₂ ¹) and that from P₂will carry the tuple (2,δ₂₁ ²). The reaction time δ₁₂ ¹ has beencomputed to be the interval between the time UM₁ is received at P₁ tothe time AM₁₂ ¹ was sent by P₁. The reaction time δ₂₁ ² has beencomputed to be the interval between the time UM₂ is received at P₂ tothe time AM₂₁ ² was sent by P₂. Thus, these two reaction times are notdirectly comparable although it is possible that if the reaction timesof both the players had been compared from the time each received UM₁,P₂ had a faster reaction time. The way the algorithm is described, giventhat all action messages corresponding to UM₁ will be processed beforeany action messages corresponding to UM₂, P₁'s action on AC₃and AC₄ willbe processed before P₂'s action on AC₃ and AC₄, thus being unfair to P₂.

To remove this unfairness, when action messages are sent by players, aset of tuples are tagged onto each of these action messages by theirproxies each representing the reaction time from the time a set ofupdate messages are received. The set of update messages, which we referto as the window, for which this information needs to be sent isindicated by the server proxy when it sends an update message. In theabove example, when P₁ and P₂ send action messages AM₁₂ ¹ and AM₂₁ ²,respectively to remove AC₃ and add AC₄, P₁ sends the tuple (1,δ₁₂ ¹)because it has seen only UM₁ when it sent this action message, but P₂sends both tuples (1,δ₂₂ ¹) and(2,δ₂₁ ²). That is, P₂ indicates that itis sending this action message with a reaction time of δ₂₂ ¹ from thetime it received UM₁ and a reaction time of δ₂₁ ² from the time itreceived UM₂. At the server proxy, message splitting is performed. Theaction message sent by P₁ is put in the delivery queue with the messagescorresponding to UM₁ and is fair-ordered based on δ₁₂ ¹ but the actionmessage from P₂ is split and inserted in two places, one with themessages corresponding to UM₁ where it is fair-ordered based on δ₂₂ ¹and the other with messages corresponding to UM₂ where it isfair-ordered based on δ₂₁ ². If. δ₂₂ ¹ is smaller than δ₁₂ ¹, the action<Remove AC₃, Add AC₄> from P₂ is delivered to the game applicationbefore the action <Remove AC₃, Add AC₄> from P₁.

A question may be raised as to why the action message from P₂ was splitand put together with the action messages corresponding to updatemessage UM₂ as well. This is because, the server proxy can only relatethe action and update messages, but has no idea about the semantics ofthe action that is being performed—as it is transparent to the gameapplication. Because of this, it has no choice, but to put the actionmessage from P₂ together with action messages corresponding to UM₂ aswell. When the “split” messages are delivered by the server proxy to thegame server, it a) indicates that this is a “split” message and b)provides the correspondence between this action message and the updatemessage to which this action message was mapped; from this, the gameserver knows the state to which the action message should be applied.Given this, the redundant “split” message should lead to a “nooperation” when it is delivered and processed by the application runningon the game server, as the action <Remove AC₃, Add AC₄> has already beenperformed by the game server. Note that the game server can filter outredundant copies of “split” messages once it knows that a message is a“split” message irrespective of the actions specified in the message.

It should be noted that action messages forwarded by the server proxy tothe game server do require extra information to be tagged. Examples ofsuch information include the update message number corresponding to theaction message as well as information about whether a message is a latemessage or a “split” message. Because application specific informationdoes not need to be passed in these messages, the fair-order algorithmsare game application transparent.

We mentioned that a window of update messages for which reaction timesare needed is indicated by the server proxy to the player proxies. Thiswindow is based on the determination by the server proxy about when tostop accepting action messages corresponding to a particular updatemessage. In the example, when UM₃ is sent by the server proxy, if it isstill accepting action messages corresponding to UM₁, which means itstill has not delivered the last action message L₁ corresponding to UM₁,it indicates the window to be [UM₁,UM₂,UM₃]. If it has already deliveredL₁, it indicates this window to be [UM₂,UM₃]. Determining the size ofthe window is an open issue. As would be understood, the game server'sapplication can help in this regard.

EXAMPLES

Let us consider an example, which illustrates the fair-order messagedelivery algorithms of the present invention by showing the computationof the delivery times. Let us take the example shown in FIG. 8 and addtiming information to it. The resulting figure is shown in FIG. 9. Thetiming information shown is in terms of a logical clock. The deliveryqueue at the time of specific events is shown in the figure, on top ofthose events. State changes trigger update messages to be sent and forthe purpose of timing calculations, it is assumed that these messagesare sent instantaneously after a state change.

Referring to FIGS. 8 and 9, the game session consists of two players P₁and P₂ and a Server. We use D^(i)(AM_(jk) ^(i)) to denote the deliverytime for action message AM_(jk) ^(i) corresponding to update messageUM_(i). Assume that the wait timeouts for the two players are W₁=10 andW₂=15. The following describes the various sequences in the gameaccording to the present invention as illustrated in FIGS. 8 and 9.

1) At time 100, the state of the game is S₁ which consists of objectsAC₁, AC₂ and AC₃. Update message UM₁ is sent by the server informing theplayers of this state. The window sent is [UM₁]. UM₁ is received at P₁and P₂. They send action messages AM₁₁ ¹ and AM₂₁ ¹. The tuples sentwith these messages are (1, 4) and (1, 3) respectively.

2) AM₁₁ ¹ is received at the server proxy (and has arrived in orderwhich is verified by looking at the sequence number), and is put in thedelivery queue. According to Definition 1, its delivery time iscalculated as D¹(AM₁₁ ¹)=100+15+4=119.

3) AM₁₁ ¹ is delivered to the server at 119 and credit for removing AC₂is given to P₁. Any action message corresponding to UM, with a reactiontime equal to or smaller than 4 that is received later will be dropped(such a message will be received only if it reaches after its waittimeout). The state of the game is changed to S₂ which consists of theobjects AC₁ and AC₃ . The update message UM₂ is sent to the players. Thewindow sent is [UM₁, UM₂]

4) AM₂₁ ¹ is received at the server proxy. This message has a reactiontime smaller than the reaction time of an already delivered messagecorresponding to UM₁ and is dropped. UM₂ is received at P₂ but is loston its way to P₁. Action messages AM₁₂ ¹ and AM₂₁ ² are sent by playersP₁ and P2. AM₁₂ ¹ carries only the tuple (1, 30) as UM₂ was not receivedat P₁. AM₂₁ ² carries the tuples (1, 37) and (2, 9).

5) AM₁₂ ¹ is received at the server proxy. This message has arrived inorder and so the delivery time for this message is calculated as D¹(AM₁₂¹)=100+15+30=145 according to Definition 1.

6) AM₂₁ ² is received at the server proxy. This message also has arrivedin order. As this message carries two tuples, it is split into twomessages and is put twice in the queue, once as an action messagecorresponding to UM₁ and the other as an action message corresponding toUM₂ (in this case, this is the first action message received at theserver corresponding to UM₂). The delivery time for the first copy iscalculated as D¹(AM₂₁ ²)=100+10+37=147. The delivery time for the secondcopy, considered in isolation with respect to action messagescorresponding to UM₂, will be D²(AM₂₁ ²)=119+10+9=138. But the actionmessage delivery times need to be correlated with other action messagessuch that all action messages corresponding to update message UM₁ shouldbe delivered before any action message corresponding to UM₂ isdelivered. Thus D²(AM₂₁ ²) is calculated as Max(147, 138)=147. Also, thedelivery time for AM₁₂ ¹ which is already in the queue is updated to beD¹(AM₁₂ ¹)=100+30=130. Assume that the current time is 145. 130 issmaller than the current time and hence AM₁₂ ¹ is delivered right away.

7) Once AM₁₂ ¹ is delivered to the server and is processed, the creditfor removing AC₃ and adding AC₄ is given to P₁. The state of the game ischanged to S₃ which consists of objects AC₁ and AC₄ . The update messageUM₃ is sent to the players. Assume that the window sent is [UM₃]. Thismeans, the server proxy does not wish to receive any more actionmessages corresponding to UM₁ and UM₂. As mentioned earlier, thedecision about the window has to be made in some fashion, may be evenwith the help of communication between the game server and the serverproxy. At time 147, two copies of AM₂₁ ² are delivered, both of whichbecomes no-ops as AC₃ has already been removed.

Let us now extend the above example to show the effect of out-of-orderreception of action messages. Refer now to FIG. 10 with respect to thefollowing discussion.

8) AM₂₂ ³ is received at the server proxy (and is out-of-order) and isput in the delivery queue. The delivery time is computed as D³(AM₂₂³)=145+max(10,15)+5=165 based on Definition 3. Note that as AM₂₂ ³ hasbeen received out of order, it is possible to receive a message from P₂with a reaction time smaller than 5 and hence the wait timeout of P₂needs to be considered. Refer to the definition of Q set forthpreviously.

9) AM₁₁ ³ is received at the server proxy (and is in-order) and is putin the delivery queue. The delivery time is computed as D³(AM₁₁³)=145+15+5=164. Again, the wait timeout of P₂ needs to be considered asthe message currently in the queue from P₂ has arrived out of order.

10) AM₂₁ ³ is received at the server proxy (and is in-order) and is putin the delivery queue. Now, message AM₂₂ ³ in the queue also becomesin-order. Using Definition 1, the delivery times of all the messages inthe queue are computed as:D ³(AM ₂₁ ³)=145+3=148D ³(AM ₁₁ ₃₁)=145+4=149D ³(AM ₂₂ ³)=145+10+5=160The delivery times for AM₂₁ ³ and AM₁₁ ³ will be smaller than thecurrent time (note that the current time is at least 150 as message AM₂₂³ has been received with a reaction time of 5 in response to UM₃ whichwas sent at time 145). These messages will be delivered with P₂ gettingthe credit for removing AC₁ and adding AC₄ . In this case AM₁₁ ³ will bea no-op.

11) The update message UM₄ is sent to the players. At time 160, messageAM₂₂ ³ will be delivered to the server and the credit for removing AC₄will be given to P₂.

The present invention provides a framework called Fair-Ordering Serviceto achieve fairness in a distributed, client-server based, multi-playergame environment. The framework consists of having proxies for both thegame server and the game players, referred to as server proxy and playerproxy, respectively. The server proxy is responsible for deliveringplayers' actions in a fair order to the game server. This is achieved bytagging messages with extra information at the origin proxy, andprocessing the extra information at the destination proxy, keeping boththe server and the players oblivious to the fair-order delivery process.This transparency allows the proxies to be used for a number ofdifferent game applications.

Although the framework is kept independent of game applications, it ispossible to use some application specific information to furtheroptimize the fair delivery of messages, that is, deliver the messageseven sooner than what has been proposed. The game application may alsohelp in deciding some of the parameters of the proxy, for example, themaximum wait timeout after which to declare an action message from aplayer too late to be delivered to the game server, or the size of thewindow of update messages opened up by the server proxy. They can betreated as input parameters to a proxy's configuration.

FIG. 11 shows an exemplary block diagram of a proxy device 110 accordingto the present invention. In general, the device includes at least twofunctional blocks, which operate in connection with a processor 120. Afirst block 130 is a queue where received transmissions are stored andwherein certain transmissions are reordered as has already beenexplained. A next block 140 is a memory device for storing instructions,for example in software, in order to carrry out the methodologies of thepresent invention. The proxy device also includes input and output ports150, 160.

For clarity of explanation, the illustrative embodiment of the presentinvention has been described as comprising individual functional blocksand/or boxes. The functions these blocks and/or boxes represent may beprovided through the use of either shared or dedicated hardware,including, but not limited to, hardware capable of executing software.Use of the term “processor” should not be construed to refer exclusivelyto hardware capable of executing software. Further, the illustrativeembodiment may comprise digital signal processor (DSP) hardware,read-only memory (ROM) for storing software performing the operationsdiscussed below, and random access memory (RAM) for storing DSP results.Very large scale integration (VLSI) hardware embodiments, as well ascustom VLSI circuitry in combination with a general purpose DSP circuit,may also be provided.

To further illustrate the present invention, we categorize updatemessages. These are messages sent by the game server to the gameplayers. There are two cases, one case is when there is only one updatemessage, therefore, all action messages correspond to this updatemessage. The other case is when there are multiple update messages,therefore, it is not clear to which update message a particular actionmessage corresponds. Obviously case one is the degenerate case of casetwo. For case two, we need to use the “message split” mechanism, whereat the player proxy, each action message is associated with a window ofupdate messages, and for each update message, a reaction time iscalculated. An action message is therefore inserted into multiple queueseach corresponding to one update message in its window.

Second, we categorize on action messages considering only one updatemessage. We have three cases: 1) when action messages arrive in orderand within their wait timeout periods, 2) when action messages arriveout of order but within their wait timeout periods, 3) when actionmessages arrive outside their wait timeout periods. Again, here case 3)is the most general case, it degenerates to case 2) and case 1).

Third, we consider a sequence of update messages, and the correlation ofaction message delivery time. When a sequence of update messages areconsidered, a delivery time formula (X) is presented taking into accountthe delivery time for the last action message for the previous updatemessage. This formula applies to cases 1), 2) and 3) since 1) and 2) aredegenerates of case 3).

The invention further illustrates a method of separating the computationof the delivery time into three scenarios: 1) when action messagesarrive in order and within their wait timeout periods, 2) when actionmessages arrive out of order but within their wait timeout periods, 3)when action messages arrive outside their wait timeout periods. Whenmessages arrive in order and within their wait timeout periods the localdelivery time of an action message at the server proxy should becalculated before being inserted to the delivery queue, and recalculatedupon new action message arrival according to Definition 1. This deliverytime guarantees that when an action message corresponding to an updatemessage is delivered, no other action message corresponding to the sameupdate message with a smaller reaction time may be in transit.

When messages arrive out of order to order messages from a specificplayer and to determine whether all earlier messages sent by said playerhave arrived, the local delivery time of an action message at the serverproxy should be calculated before being inserted to the delivery queue,and recalculated according upon new action message arrival according toDefinition 3. When messages do not arrive within wait timeout.—i.e. whennot to accept any more action messages corresponding to a updatemessage, the local delivery time of an action message at the serverproxy should be calculated before being inserted to the delivery queue,and recalculated according upon new action message arrival and actionmessage delivery according to Definition 3. Using this reasoning, we usethe formula (X) combined with update message window, “message splitting”mechanism as the generic algorithm to implement in the framework.

The foregoing description merely illustrates the principles of theinvention. It will thus be appreciated that those skilled in the artwill be able to devise various arrangements, which, although notexplicitly described or shown herein, embody the principles of theinvention, and are included within its spirit and scope. Furthermore,all examples and conditional language recited are principally intendedexpressly to be only for instructive purposes to aid the reader inunderstanding the principles of the invention and the conceptscontributed by the inventor to furthering the art, and are to beconstrued as being without limitation to such specifically recitedexamples and conditions. Moreover, all statements herein recitingprinciples, aspects, and embodiments of the invention, as well asspecific examples thereof, are intended to encompass both structural andfunctional equivalents thereof. Additionally, it is intended that suchequivalents include both currently known equivalents as well asequivalents developed in the future, i.e., any elements developed thatperform the same function, regardless of structure.

In the claims hereof any element expressed as a means for performing aspecified function is intended to encompass any way of performing thatfunction including, for example, a) a combination of circuit elementswhich performs that function or b) software in any form, including,therefore, firmware, microcode or the like, combined with appropriatecircuitry for executing that software to perform the function. Theinvention as defined by such claims resides in the fact that thefunctionalities provided by the various recited means are combined andbrought together in the manner which the claims call for. Applicant thusregards any means which can provide those functionalities as equivalentas those shown herein. Many other modifications and applications of theprinciples of the invention will be apparent to those skilled in the artand are contemplated by the teachings herein. Accordingly, the scope ofthe invention is limited only by the claims.

1. A method of providing a fair exchange of messages to players of adistributed multi-player game taking place over a communicationsnetwork, said method comprising the steps of: utilizing a multi-playergame server that generates update messages to said players and receivesaction messages from said players; delivering said action messages forprocessing by said game server in an order of increasing reaction time,reaction time being a difference between reception of an update messageby a player and a sending of an action message by said player inresponse to said update message.
 2. The method of claim 1, wherein agame server proxy is operable in connection with said game server forreceiving and ordering of said action messages and forwarding saidaction messages to said game server.
 3. The method of claim 2, whereineach action message received at said game server proxy is delayed untila computed delivery time is reached to ensure fair processing of theaction messages sent from all players.
 4. The method of claim 2, whereinsaid server proxy associates a message number with the update messagessent to said players thereby tracking an update message to which anaction message responds.
 5. The method of claim 2 wherein said serverproxy records a sending time for an update message and associates saidupdate message with a sending time.
 6. The method of claim 2, wherein aplayer proxy is operable in connection with said game server forreceiving said update messages from said game server and forwarding saidupdate messages to said game players, and for receiving said actionmessages from said game players and forwarding said action messages tosaid game server.
 7. The method of claim 6, wherein a player proxyrecords reception time of an update message and uses said reception timeto calculate said reaction time once action message is sent by a player.8. The method of claim 6, wherein said player proxy sends an updatemessage number, reaction time and action message number with an actionmessage.
 9. The method of claim 6, wherein a message split mechanism isemployed at said player proxy when multiple update messages areoutstanding, each action message associated with a window of updatemessages, a reaction time being calculated for each action message withrespect to each said outstanding update message.
 10. The method of claim3, wherein the wait timeout period is calculated by some multiple of theexpected round trip time between said server proxy and player proxy. 11.The method of claim 1, wherein an appropriate delivery time formula foran action message is utilized depending on whether action messagesarrive in order and within their wait timeout periods, action messagesarrive out of order but within their wait timeout periods, or actionmessages arrive outside their wait timeout periods
 12. The method ofclaim 2, wherein said server proxy, when an action message is received,computes a position in a queue where said action message should beinserted and a local delivery time at which said message is to bedelivered to said game server.
 13. The method of claim 12, wherein saiddelivery queue is kept sorted based on message number and reaction time,respectively.
 14. The method of claim 11, wherein the delivery time ofan action message at a server proxy is calculated before being insertedto a delivery queue, and recalculated upon new action message arrivalwhen messages arrive in order or out of order but within their waittimeout periods.
 15. The method of claim 11, wherein action messagenumbers are used by a server proxy when messages arrive out of order toorder messages from a specific player and to determine whether allearlier messages sent by said player have arrived.
 16. The method ofclaim 11, wherein delivery time of an action message at a server proxyis calculated before being inserted to the delivery queue, andrecalculated upon new action message arrival and action message deliverywhen messages arrive outside of the wait timeout period.
 17. The methodof claim, 6 wherein, when action messages are sent by players, a set oftuples are tagged onto each of the action messages by their proxies eachrepresenting the reaction time from the time a set of update messagesare received, wherein a window for which this information needs to besent is indicated by the server proxy when it sends an update message.18. The method of claim 6, wherein a window of update messages for whichreaction times are needed is indicated by the server proxy to the playerproxies, the window being based on the determination by the server proxyabout when to stop accepting action messages corresponding to aparticular update message.
 19. A method of providing a fair exchange ofmessages to players of a distributed multi-player game taking place overa communications network, said multi-player game generating updatemessages to said players and receiving action messages from saidplayers, said method comprising the steps of: receiving an updatemessage from said game server at a player proxy; recording receptiontime of said update message at said player proxy; and calculating areaction time using said reception time, said reaction time transmittedby a player in connection with an action message.
 20. The method ofclaim 19, wherein said player proxy sends an update message number,reaction time and action message number with an action message.
 21. Themethod of claim 19, wherein said reaction time is used by saidmulti-player game to order responses by said players to thereby providesaid fair exchange of messages.
 22. A system including computer readablecode including instructions for use by a server operating in connectionwith a distributed multi-player game, said instructions providing a fairexchange of messages to players of a distributed multi-player gametaking place over a communications network and comprising the steps of:generating update messages to said players and receiving action messagesfrom said players by way of said server; delivering said action messagesfor processing by said game server in an order of increasing reactiontime, reaction time being a difference between reception of an updatemessage by a player and a sending of an action message by said player inresponse to said update message.
 23. The system of claim 22, furtherincluding code for use by player proxies of said multi-player game, saidcode being operable to: receive an update message from said game serverat a player proxy; record reception time of said update message at saidplayer proxy; and calculate a reaction time using said reception time,said reaction time transmitted by a player in connection with an actionmessage.
 24. The method of claim 23, wherein said player proxy sends anupdate message number, reaction time and action message number with anaction message.
 25. The method of claim 23, wherein said reaction timeis used by said multi-player game at said server proxy to orderresponses by said players to thereby provide said fair exchange ofmessages.
 26. The method of claim 22, wherein an appropriate deliverytime formula for an action message is utilized at said server proxydepending on whether action messages arrive in order and within theirwait timeout periods, action messages arrive out of order but withintheir wait timeout periods, or action messages arrive outside their waittimeout periods
 27. The method of claim 22, wherein a server proxy, whenan action message is received, computes a position in a queue where saidaction message should be inserted and a local delivery time at whichsaid message is to be delivered to said game server.
 28. The method ofclaim 3, wherein said delivery time is based on a given wait timeoutperiod.
 29. The method of claim 12, wherein an action message beinginserted into multiple queues corresponding each to a respective updatemessage in its window.